Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Top down and bottom up refers to different methods of design
Transcript of Top down and bottom up refers to different methods of design
Entity analysis is when particular entities within a diagram are scrutinised. This means that the position of a specific entity can be determined within a database/databases. This allows the chore of keeping track of certain entities to be easier rather than manually scanning through each of them.
Degrees of relationships
or cardinality refers to the relationships of the database and can include the previously mentioned relationships as well as n-ary relationships which means that an n-ary relation in which it’s degree is “n” in turn of a relation of “n” attribute/attributes.
Top Down and Bottom Up
Top down and bottom up refers to different methods of designing a database. A developer can choose to begin with a single, top point to develop downwards from such as with a hierarchical database. This means that a single entity can be selected to design from as a parent with child fields to eventually grow downwards. The bottom up style is the exact opposite of this where the developer works upwards which is usually less forgiving as working from a top down method allows more freedom and ease in most cases as it is usually considered easier to design from a single point which branches out downwards.
Entity relation diagrams
Entity relation diagrams (ERD’s) allow entities to be represented on-screen as graphical diagrams. Relationships are formed and then connect to other pieces of data which are then connected further to what are known as attributes. There are three ways to portray their relationships: One-to-one, one-to-many and many-to-many.
Different Approaches to Database Design
Functional dependency is also known as database dependency and involves one attribute determining the outcome of another. This can be shown as A -> B meaning that attribute B is functionally dependant on attribute A such as a member of a library being identified by their library membership number as it is possible for one member to have the same name as another and, without membership numbers being linked to their names appropriately, errors and complications can occur.
This relates to the need to normalise a database. There are 5 ways of normalising a database but there are usually just 3 commonly used methods of achieving this. The first being the normalisation in place to compact the database by usually by removing any blank instances. Naming conventions are essential when normalising data. A primary key is needed and the table must have a primary key which is usually some sort of ID number to avoid any individuals with the same name causing any errors. When normalising for the first time, no one attribute can have multiple values. Non-key attributes in a table depend upon the primary key and an individuals name must depend on their ID.
are entities that contain either an integer numeric ID or a key name and act as a parent to various other entities structurally.
is what describes the relationship between the entities within a database diagram. This is in terms of the degree of the relationship, the membership class and the attribute domain.
One-to-one means that one entity is solely connected to another.
One-to-many is when one entity is linked to multiple entities. An example of this is if there is a library with a large amount of members.
Many-to-many refers to multiple entities connecting to multiple entities. An example can be a database involving individuals and their locations. Someone can be from England, but also from Britain, whilst also being from Europe just like someone from Scotland.
The second normal form continues from the first as data tends to have gone through the first form of normalisation. This, however means that if the data that contains the primary key alone and one attribute, it is automatically in the second normal form. This is removing any duplicate entries in the table, also if the primary key is composed of more than one attribute, the non-key attributes must depend on the complete primary key.
The third normal form occurs when the data has been sorted into the second normal form and each non-key element in the table does not depend on another non-key element. This can cause problems with information being linked either to the wrong attribute or data becoming vague as it is passed through multiple linkages within the data.