数据建模:逻辑建模练习

Question

在尝试学习数据存储的艺术时,我一直在尝试尽可能多地获取可靠的信息.PerformanceDBA在以下帖子中发布了一些非常有用的教程/示例:我的数据是否已标准化？和关系表命名约定.我已经在这里询问了这个模型的子集问题.

因此,为了确保我理解他提出的概念,我在其他地方看到过,我想进一步采取一两步,看看我是否掌握了这些概念.因此这篇文章的目的,希望其他人也可以学习.我所呈现的一切都是对我和学习的概念,而不是在某些生产系统中应用它.自从我使用他的模型开始以来,从PerformanceDBA获得一些输入会很酷,但我很欣赏任何人提供的所有输入.

由于我是数据库的新手,尤其是建模,我将首先承认我可能并不总是提出正确的问题,清楚地解释我的想法,或者由于缺乏关于该主题的专业知识而使用正确的问题.因此,请记住这一点,如果我偏离轨道,请随时引导我朝正确的方向前进.

如果对此有足够的兴趣,我想从逻辑到物理阶段采取这种方式来展示过程的演变并在Stack上分享它.我将为逻辑图保留此线程,并为其他步骤启动新线程.根据我的理解,我将最终构建一个MySQL数据库来运行一些测试,看看我想出的是否真的有用.

以下是我想在此概念模型中捕获的内容列表.编辑V1.2

1. 这样做的目的是列出乐队,他们的成员,他们将出现的活动,以及提供音乐和其他商品出售
2. 会员将能够与朋友匹配
3. 会员可以在乐队,他们的音乐和他们的活动上撰写评论.
   • 每个成员在给定项目上只能进行一次审核,尽管他们可以编辑他们的评论并保留历史记录.
   • BandMembers将有机会撰写关于他们所关联乐队的评论的单一评论.作为乐队,每次评论只允许一个评论.
   • 然后,成员可以对所有评论和评论进行评级,但每个给定的实例仅评
4. 会员可以选择自己喜欢的乐队,音乐,商品和活动
5. 乐队,歌曲和事件将被分类为它们所属的类型,然后在必要时进一步细分为SubGenre.Band或Event可以归入多个Genre/SubGenre组合.
6. 将为特定乐队发布活动日期,时间和地点,会员可以显示他们将参加活动.活动可以由多个乐队组成,多个活动可以在同一天的单个地点举行
7. 每一方都将至少与一个地址绑定,并保留地址历史记录.每个方也可以一次绑定多个地址(即计费,运输,物理)
8. 将存储Bands,BandMembers和一般成员的配置文件.

所以它可能有点涉及,但对于许多人来说可能是一个很好的学习工具,因为这个过程在不断发展,社区也会提供意见.有什么输入？

编辑v1.1 响应PerformanceDBA

U.3)这意味着数据库中没有Band商品以外的商品.正确吗？ 这是我最初的想法,但你让我思考.也许该网站想要出售自己的商品甚至是乐队的其他商品.不确定为此做出的模式.它是否需要对目录部分进行整个返工,或者只需要与乐队存在的识别关系？试图销售完整的专辑或歌曲的mod.无论哪种方式,它们都是电子格式,只能下载.这就是为什么我将专辑列为由歌曲组成而不是两个独立的实体.

U.5)我理解你提出的关于与Favorite的循环关系的内容.我想谈谈这个"它是一个具有某种形式的差异的实体(FavoriteType),它确定了它的处理方式"但我怎么不清楚.我在这里错过了什么？

u.6) "业务规则这可能是你唯一的弱点."
感谢您的诚实回应.我将重新阅读这些内容,但我希望首先通过回复给您的回复清除我脑中的一些疑惑.

Q.1)是的我希望接受,拒绝和阻止.我不确定你指的是如何改变逻辑模型？

Q.2)一个人不一定是用户.它们只能作为BandMember存在.那是你在问什么？

次要问题

零,一个或多个...哎呀我承认我在构建模型时忘记了这个注意事项.我按原样提交此版本,并将在未来版本中解决.我需要阅读更多关于约束检查的内容,以确保我理解事物.

M.4)取决于您将来是否设想OrderPurchase.你能扩展一下这里的意思吗？

编辑V1.2 响应PerformanceDBA输入...

得到教训.

1. 我正在混合识别/不识别和基数(即类型/子格)的概念,并且这样做不一致,使事情变得更糟.
2. 逻辑图中不需要关联表,因为它们可以描述多对多关系,然后在物理模型中进行扩展.
3. 在很多关系中我忽略了基数
4. 使用有效的动词短语来阅读关系的重要性,以确保我正在模拟我想要完成的事情.

U.2) 在该模型的概念中,只需要将场地作为事件的位置进行跟踪.无需收集更多数据.据说,活动将在特定的EventDate上进行,并将在场地举行.场地将在给定日期举办多个活动和可能的多个活动.在我的新模型中,我的想法是EventDate已经与Event绑定.因此,Venue不需要与EventDate建立关系.你在U.2)下列出的第5和第6发子弹让我质疑我的想法.我在这里错过了什么吗？

U.3)是时候将Item和Band之间的链接移动到Item和Party了吗？根据目前的设计,我没有看到有可能出售与你乐队无关的商品.

U.5)我按照你的输入离开,而不是使它成为一个离散的超类型/子类型关系,因为我没有看到这种类型的卷起的好处.

其他修订

AR.1)在完成对FavoriteItem的练习之后,我觉得要审核的项目需要多对多关系才能显示出来.必要？

好的,我们去v1.3

我在这个版本上花了几天时间,按照我的设计来回走动.一旦逻辑过程完成,我想看看我是否走在正确的轨道上,我将深入了解我所学到的知识以及我作为初学者在整个过程中遇到的麻烦.这个版本的重点是投入了一些密钥以帮助看到我过去缺少的东西.经历矩阵的过程也证明了它的巨大帮助.无论如何,如果不是因为PerformanceDBA提供的输入,我仍然会是一个在黑暗中琢磨的失落的灵魂.谁知道我现在的设计可能会重申我仍然是,但我学到了很多,所以我知道我手里至少有一个手电筒.

在这个时候,我承认我仍然对识别和非识别关系感到困惑.在我的模型中,我不得不使用非空值的非标识关系来加入我想要建模的关系.在阅读这个主题时,似乎在这个问题上存在很多分歧和犹豫不决,所以我做了我认为在我的模型中代表正确事物的东西.何时强制(识别)和何时自由(不识别)？有人有投入吗？

编辑V1.4

Ok拿了V1.3输入并清理了这个V1.4

目前正在开发V1.5以包含属性.

编辑V1.6

好吧,自从我在这里发布以来已经有一段时间了但是这个项目的工作仍在进行中.我现在正在发布V1.6,其中包括V1.4上次发布的一些更改.此版本显示了Keys的进一步发展.它仍然不包括属性或任何AK或IE.我已经开始研究物理模型,并使用它来帮助处理属性,并尝试阐明我在定义AK和IE时遇到的问题.逻辑模型的下一个发布将包括这些键和属性.

Answer 1

Acknowledgement

I have to say, you have done a fantastic job at (a) grasping the Modelling elements provided in your previous question and (b) applying them. You have come a long way in just one day. It is a wonderful reinforcement of the fact that, given the correct education, capable people are empowered to do great things, to go off own their own power.

Method

Given your stated objective, and your demonstrated capability (not to mention, the first seeker I have dealt with on SO, for Db Design questions who has posted an ERD instead of a bunch DDL), I won't supply answers. I will give you directions and guidance, and you will have to progress your own model.

当然,我也将介绍具体内容,但我将完全覆盖一两个主题领域,而不是全部.您可以选择它并将其应用于所有主题领域.

我没有回应核心主题领域,因为我们仍在处理识别实体.当这个解决了Reviews,等等会更容易; 交易实体取决于识别实体.

方向

D.1) I know that I stated that I need to see the whole model. There is one exception. Historic or Temporal or Audit data (eg. the Edit and stored versions). At this early stage, they can be set aside; to be implemented just before completion of the Logical Model. This is in recognition that (a )they are simple Dependents of some parent (b) the parents need to be modelled in relation to all other tables first, and (c) to exclude unnecessary complications, and thus allow us to concentrate on the relevant field.

• in particular, you can ignore the tense in the Verb Phrases (every location of a version table would otherwise require Has/Had). Stay with present tense for now, because the focus is modelling, not archiving.

Unresolved

U.1)可选的父
完全禁止.不仅仅是IDEF1X,还有诚信的任何概念.如果定义了FK参考,那么必须有父.要允许可选父项,必须删除(或不实现)FK参考.根据定义,这样的条件会将结果排除在称为"关系数据库"之外.例如.Address:Order.

• 当然,在发达国家,Order必须有Address法律或税收原因; 这与标准要求问题是分开的.
  .

U.2) Event
Party::PartyAddress is correct; Address::PartyAdress is correct. Event::Address needs work. Address is an Identifying Reference table; if used, it would be the parent, Event would be the child. I leave it to you to identify/model multiple Events to a location, and Events at one or multiple locations.

• There may be a Venue involved. Or a EventOccurrence

• But if it is a generic Event which happens at multiple locations, that does not need an Entity, the Address is already in Order.

U.3) Assuming Catalog is an entry in the traditional sense (JCPenney 2011), a list of items for sale or hire.

• OrderSaleItem is correct

• Critical point. Catalog is Dependent, and can exist only in the context of a Band, as an Assset. Fine. That means no merchandise other than Band merchandise in the database. Correct ?

• 我可以看到"蓝调兄弟的晚间表演"是Event如何订购,开具发票和付款的.还评论,评论等

• 我看不出那是怎么回事Song.乐队是否销售专辑,歌曲或两者？

• 没有其他乐队的合作:音乐会/活动纪念品; 海报; 刻有镜头的眼镜？

• 与您引用的命名约定以及数据库的其余部分Catalog(强效)一致应该命名Item(行).你已经(自然地)使用了它OrderSaleItem,(而不是OrderSaleCatalog.

U.4)类型

• 没问题an Item is classified by one-to-many Genres.

• 我想另外a Genre classifies one-to-many Items.Relation是一对多的(当我们到达Physical时,它将被解析为一个关联表).

U.5)喜欢
的基数Item::Favorite被颠倒了.当您更正时,Favorite主题区域将需要进一步建模.

• 同一对实体之间的循环关系或双路径是未解析模型的信号.通常一个是正确的,另一个是多余的.(有例外,但不是这里;当发生这种情况时,动词短语将它们区分开来.)

• 无论是Band::FavoriteXOR Item::Favorite是正确的,不能同时使用.

• Item::Favorite似乎是正确的,因为Band已经确定了Item

• Likewise, one Favorite Entity for bands and merchandise does not sound solid. Every Identifier in the single Favorite Entity is a Party. It would break when we Normalise, might as well demand that the Identifiers be clarified at this stage. It is either one Entity with some form of differentiation (FavoriteType) which identifies its treatment; or one Favorite for bands and another for merchandise, in which case differentiation is not required, ambiguity is eliminated.

U.6) Business Rules This is probably the only area you are weak in. General response. You have done the tasks separately (all the modelling vs writing BRs). These do not match the model. When you go through the next cycle, take the Business Rules as directives, and modulate them at the same time, as with the Entities, the Relations, and the Verb Phrases.

Question

Q.1) User/Friend
You have the essence of it perfectly. And the Cardinality of the Relations. (Full treatment on this one.) That is correct for Accepted Friend.

• therefore the tense should be past (go with the majority rows)

• Requested, and pending Accepted, are the minority. Easily implemented in a IsAccepted Bit or Boolean.

• Later you may have IsRejected or IsBlocked (that latter should be a separate Entity).

• Is that what you require ?

Q.2) What is the basis on which a Person is zero-to-many Users ?

Minor Issue

M.1) Singular only.

M.2) Party Has zero-to-many Addresses. I would think they must have one, in order to transact business (but perhaps not for all Users).

M.3) Order May Have zero-to-many Payments. "Requires" means that first Payment has to be inserted at the same time as Order.

• Likewise, for any mandatory children (one-to-many as opposed to zero-to-many) that first child must be inserted at the same time as the parent. This is done via Transactions in enterprise databases, because Immediate Constraint Checking (not Deferred) is implemented; and the small end of town fight over silly things like Deferred Constraint Checking is "better" and then spend half their life figuring out how not to get caught in the infinite loops they created, which trap them. MyNonSQL does not have any at all, so nothing to worry about for this implementation.

M.4) OrderSaleItem shoulld be OrderItem xor Order should be OrderSale. Depends if you envision OrderPurchase in the future.

?Subject Area Example?

Readers who are unfamiliar with the Standard for Modelling Relational Databases may find ?IDEF1X Notation? useful.

As stated, I am not providing a finished Data Model, only guidance. This is just one progression of one selected Subject Area. It is not "right" or complete in any way.

• Your Verb Phrases are excellent. I have provided alternatives for you to consider, they are not "right" or "better". you need to choose an progress them or your own. The goal being the most concise and accurate VP in each case.

• No suggestion that Person is correct and User is incorrect, that is pending your answer. But I had to use something in the model; since you have modelled them as separate, a counterpoint may be interesting to evaluate.

Ok, so go ahead and progress the model, then post again (just edit the question, leaving the header paras, and replacing the rest).

V1.1 and Response

That is certainly a progression.

I have re-numbered the items in pseudo-legal format, including the section headings, so that we can keep the numbering throughout, and keep adding to it. Actually it really eases the SO editing problems as well.

U.3) Would it require an entire rework of the Catalog section or just the identifying relationship that exists with the Band?

• No. That's the great thing about working at this level, the decisions you make here will be the railroad tracks that the data runs on, as freight, or does not run on (and thus needs alternate transport and heavy lifting to derive, in the form of masses of code or an additional data warehouse). And the decisions here are cheap (modelling time, paper).

• Right now an Item exists only in the context of a Band. It is Dependent. To allow non-band merchandise, it needs to be Independent. And then the existing super/subtype cluster needs rework.

Attempted a mod to sell both complete albums or song. Either way they would both be in electronic format only available for download. That is why I listed an Album as being comprised of Songs

• Ok. But now you can only sell albums, not songs.

rather then 2 separate entities.

• Not sure what you mean (you have two separate entities).

• It appears you have not seen my ?Subject Area Example?. Note that if you open it now, it contains bits that I have added V1.1; I have not changed what was there yesterday, the V1.0 response.

• Actually that means you should go through my V1.0 Answer again, while viewing the Example.

U.5) ... but how to is not clear to me. What am I missing here?

• An example of one Entity with differentiation is any of the Supertype/Subtype clusters you have. The Favorite is the Supertype, BandFavourite and ItemFavourite are subtypes; allowing each to reference to Band xor Item respectively.

• You have modelled ItemFavourite. Now the question is, does the fact of a ItemFavourite imply that the Band is Favourite; or is BandFavourite a discrete fact ? In the example, I have modelled the latter, without the Favourite::ItemFavourite/BandFavourite structure.

Q.1) Yes I would like to have Accepted, Rejected, and Blocked. I am not sure what you are referring to as to how this would change the logical model?

• No change (I already stated it was pretty complete) to V1.0, but you might need an additional Entity.

• You need three Bit or Boolean indicators in Friend. That will service these statuses:

  • Requested (but not Accepted)
  • Requested & Accepted
    .
• But Blocked is not a Friend (or could have been a Friend previously, but not since being Blocked). So either the Entity name has to change to reflect that (no change to the two Relations) xor Blocked has to be a separate Entity. Two separate meanings for the second Relation leads to complexity, therefore I would go with the latter.

With the former, we have additional statuses:

• Blocked
  .
  • Then the Verb Phrases need change (and I will include the RoleName for clarity), and one of them has a alternate meaning. .
  • (It will be much more clear at the Attribute level Model, that's why we model in pictures, not words; so I have included it.)

Q.2) A person does not have to be a User. They can exist only as a BandMember. Is that what you are asking?

• No. Why do we need to differentiate Person and User ? What are the separate actions or attributes ? Thus far, I see Person and User as the same Entity; Person is an User with no activity.

• This is the last item, holding us back from dealing with the core Subject Area.

M.3) I need to read up more on Constraint Checking to make sure I am understanding things.

• Don't worry about that now; I was giving you reason to keep it simple (the NonSQLs appear to simplify things but actually they make it more complex). MyNonSQL has none of those capabilities, so you can eliminate consideration of the platform, and just model the Cardinality meaningfully.

M.4) Depends if you envision OrderPurchase in the future. Can you expand as to what you mean here?

• In the context of the Model. You provide the structures to make SalesOrders (of Items). Therefore Item, Order and OrderItem.

• But if you provided the structures to track PurchaseOrders as well (to purchase Items as well as office supplies, rent, whatever), then you need to differentiate Sales Orders and Purchase Orders. Therefore:

  • Item
  • OrderSale and OrderSaleItem
  • OrderPurchase and OrderPurchaseItem

Version 1.1

U.2) Event Progressed

• EventDate looks good. I would define the Relation as Event Was Perfromed On EvenDate.

• Whereas ItemGenre is perfect, Event::Venue Needs work. This is a mistake you make consistently, so an explanation is called for.

  • You have modelled Venue correctly, it is Independent and does exist outside the context of Event. But Event May Be [Held] At zero-to-many [Independent] Venues is not possible.

  • Events are held at many Venues, and Venues host many Events. If that was all, since this is the Logical Level, you can draw a many-to-many Relation, and you are done. At the Physical level, that Relation is resolved by implementing an Associative Table, of which the PK is the two parent PKs, and there is no data. (Enemy is a good example.)

  • But if there is data (eg. you need to track the date or number of attendees or whatever), then it is not an Associative Table, it is another Entity. A Thing that Takes Place between Event and Venue.

  • EventDate is a good candidate. We already have that, and the date. Just add Venue and stir. I would call the Thing that Takes Place between Event and Venue a Performance.

• Likewise, EventAddress has progressed but is not complete.

  • Do Events have Addresses or Venues have Addresses ? (model it, no need for words)

  • If Venue: do you need all the historic Addresses for the Venue (like Party), or just the current one (like Order) ?

M.5) SubGenre. Can you explain why SubGenre is (a) Independent and (b) the Relation is Non-Identifying.

M.6) Item Is zero-to-many Favourites. Therefore: Item Is a Favourite of zero-to-many Users. Likewise, Each User Chooses zero-to-many Favourites. Therefore Each User Chooses zero-to-many Favourite Items.

V1.2 and Response

Great Progress.

U.2) Event Further Progressed

Going by your Edit as well as the new Requirements, some yes and some no. All the other Subject Areas of the Data Model are pretty much complete (for Logical), this one area is confused, not nearly as resolved. Partly because of the added Requirements (no complaint, that happens in real life; it is about how you handle it).

The main point I will make here is that the Data Model should always model the real world, as opposed to only the business Requirement. That (a) insulates the DM from the effect of change and (b) provides a solid platform for added Requirements. That does not mean you have to model the whole real world, but the parts of it that you do model must reflect reality and not be squished up to fill just the Requirement.

Second, there is lack of clarity about the distinctions between Event, Band-Event, Performance, etc. Right now an Event is a Party-Band-Item-Event. That's fine, but it does not work for the new style Event per Requirement.

Third, you have a good handle on Address re Party and Order, but not re Venue.

• Since you are accepting the Standard-compliant model and therefore the treatment, Address is a Reference table.

  • It is Independent (square corners)

  • Actually, you can place Address and everything above it on page one; making this part of the model page two, and have Address only on this page.

  • Correctly modelled: A Party has a history of Addresses. They must have at least one current { IsBilling | IsShipping | IsPhysical } Address, based on whatever activity is being executed.

  • Correctly modelled: An Order has one IsBilling Address (if you need IsShipping, you need to add a separate Relation).

• Address is not a child of Venue (also Independent, correct). I do not think a Venue is located in zero-to-many Addresses. (Maybe that is the old Cardinality-reversed bug, but I am not sure, due to the other confusion re Event and Venue.)

• Actually Address::Order is suspicious. (Q.3) Do you want Order to reference any valid Address, or a specific address for the Party executing the Order ?

• Back to Event. Accepting EventDate as declared. That's fine but then Reviews etc, apply to the generic concert and not the single concert which they performed on mushrooms. Go for V1.3.

  • Your terminology re Event, etc is consistent with the Requirement, etc. but it does not support the Requirement as stated.

  • So let us start using "Event" the way it is used in the real world, and model it that way. What we have been calling "Event", the Party-Band-Item, is actually a Performance. And not a generic one that is scheduled, but a single one at a specific Venue.

  • That is either what you meant with EventDate, or EventDate resolves into Performance.

If you do not mind, I will avoid typing one thousand words, and give you a picture. ?Subject Area Example V1.2?

• Notice that the multiple Bands per Event is resolved.

• And the Verb Phrases are straight from heaven. An Address hosted multiple Venues, each of which catered multiple Events, each of which is multiple Performances, each of which is one Party-Band-Item.

U.3) Is it time to move the link between Item and Band up to Item and Party instead? With the current design I don't see a possibility to sell merchandise not tied to the band as you have brought up.

• First, we need to use Relational terminology, not because I am a pedant, but because the real gurus say it really helps to make the transition to the Relational world.

• Second, we cannot accomplish that by "moving the Relation".

• You have to model non-Band merchandise: how you are going to sell it; track it; get paid for it. Whether you want Reviews and Responses, etc. I do not see what Party has to do with it, and right now we are selling Band-Items, not Party-Items. Consider the Referential Integrity issues.

Version 1.2

AR.1) After going through the exercise for FavoriteItem, I feel that Item to Review requires a many-to-many relationship so that is indicated. Necessary?

• In V1.1, An Item had many Reviews, and a Review was about one Item. A Person generated many Reviews (one per Item). That is logical.

• A Review is about many Items is not reasonable.

  <