This presentation was delivered to the Silicon Valley Code Camp in a session entitled "Introduction to Database Design with Entity Relationship Diagrams" on October 9, 2011. The intent of the presentation is to teach people how to understand, create and work with ER diagrams. There are also a number of topics introduced for the purpose of stimulating self-directed learning after the presentation.
The presentation featured a demo where the audience participated in the design and normalization of a database in real time.
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
Introduction to Database Design with Entity Relationship Diagrams
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
Notes de l'éditeur
25-30 minutes of instruction, 15-20 minutes of demo, 30+ minutes of Q&AI hope I’ll address most of your questions, so write them down + let’s talk about them at the end of the slidesBut if you don’t understand something, please interruptFirst off, I’d like to see where you’re at – where are you with your understanding and experience w/modeling?Comfy with SQL? Write a join query? Have done modeling before? Dealing with someone else’s mess
Edgar F.Codd – British IBM researcher, regarded as the inventor of the relational model for database managementGOALS FOR SESSION: At the end of this session, you should be able to read, understand and create database Entity Relationship diagramsThere will be a couple of exercises for the audience as we go and an Interactive demoQ&A – very curious about what you’re facing out there in the world
Want you to know of any bias that may affect my talkCheck out November 7thMeetup all about Tools, Tools and More Toolswww.bizsparksf.com
Visual representation of the ENTITIES and RELATIONSHIPS between themBased on rules from the real world / your business; Entails a number of rules, standards and guidelinesGreat way to communicate with co-workers, customers, developers; Great working model and critical reference documentYou could consider this as a whole bunch of linked-together Excel worksheets: these fields define the columnsWorking with a model is 50% science, 50% art, 50% experience
C’mon, you have to put all that data *somewhere*!Fun? YES! It’s a great mental exercise that forces you to think through a lot of hard problemsSeparation of Concerns (1974, check Wikipedia)
Entity = object that is important to the business.Entity = the NOUNRelationship = how are these objects/entities relating to one another?Relationship = the VERB; the VERB PHRASE
CustomerId in SalesOrder table references a record/row in the Customer tableWe can look up / refer to related or seemingly unrelated data elsewhere
What’s in a name?Naming conventions – singular vs. plural DESCRIBE THE BUSINESSAttribute = property of an Entity = Columns of database tableData type choice (decimal vs. float vs. money) varchar vs. nvarchar vs. char vs. textNULL option – is this attribute mandatory or required per business rules?Primary Key: unique identifier for each row of dataForeign Key: some other entity’s primary key that appears here due to some relationship between the twoIDENTITY column: guarantees uniqueness and auto-increments (autonumber). (1,1) specifies the SEED and INCREMENT
Not just a Facebook statusA relationship is the “verb” between entities – defines how they interact per business rulesNaming / “writing a sentence”Defines how the entities interactRead the relationship from parent->child (end with the dot)Identifying: the child is dependent on its parent for its identityNon-identifying: may be existence dependent but not identity dependent
Sometimes we end up with odd relationships and don’t know whyAssociative / link / join / junction table: used for many-to-many tablesCan make joins a little more difficult but is a common patternGREAT for when you want to use an entity in other areas, e.g. Customer<->Address and Person<->Address
Cardinality: how many instances of each entity may be involved or must be involved?w/ identifying – there has to be one Customer for some # of Addressw/ non-identifying – no requirement to have a Customer to have an Address (could be an Employee Address, Order Address, etc.)<nothing> One-to-zero-or-more:<P> one to one or more<Z> one to zero or one<N> one to exactly Nw/ non-identifying relationships, these can all be zero-or-one-to…
Primary Key – unique identifying key (can be any data type as long as it’s unique)Foreign Key – some other entity’s PK that appears here because of some relationship with itCandidate Key – Could this work as a PK? What’s are the candidate keys in this table?Composite Key – put a few fields together to get a unique keyStrings? Timestamps? Integers? Decimals?
DENORMALIZED:Data can be duplicated and get out of syncEase of queryingPerformance considerationsNORMALIZED:One “fact” occurs in one place and only one placeRequires you to get the business rules “right”No way to have data concurrency issuesDoes require a lot of joins
Great opportunities for self-directed learningCascading deletes
In some ways it’s easier to create than repair… let’s work together to see how we can improve this modelFirstName/LastName fields long enough?StateProvince field?Website (255) OK?Are all of these fields really OK to be nulls?WTF is OwnerId doing in Country? State?Is StateCode and CountryCode OK for a PK? Why not a bigint?Relationships in wrong directionDenormalizedInfo? What is this? A flag?
Features + benefits of these as you go up/down the food chain