Jump to content

Talk:Cardinality (data modeling)

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Dirk Hoeschen (talk | contribs) at 10:23, 3 December 2015 (This article is also low on examples). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
WikiProject iconComputing Stub‑class
WikiProject iconThis article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
StubThis article has been rated as Stub-class on Wikipedia's content assessment scale.
???This article has not yet received a rating on the project's importance scale.
Note icon
This article has been automatically rated by a bot or other tool as Stub-class because it uses a stub template. Please ensure the assessment is correct before removing the |auto= parameter.

Can't a doctor have multiple patients and a patient multiple doctors? Wouldn't the example mentioned then be of a many-to-many and not many-to-one type?

Well it seems to be correct there: there is a many-to-many example regarding doctors and patients and one-to-many between doctors and departments. Zeratul021 (talk) 21:12, 15 January 2009 (UTC)[reply]

In this article the relational model is mixed up with ER-Modeling! There is no n:m relationship between relational tables. In ER modeling the cardinality of a relationship type is a constraint that limits the number of potentially related entities.

In the relationsal data model the cardinality of a table is the number of tuples (rows) in that table. —Preceding unsigned comment added by 84.147.211.226 (talk) 21:02, 7 May 2010 (UTC)[reply]

This article is crap. Firstly, the previous commenter is correct, the cardinality of a table is the number of distinguishable rows in that table. However, a far more common use of the term in datamodelling is in respect of a column or combination of columns. In this context the term refers to the degree to which a column value differentiates its row from other rows: a column with "high cardinality" is a good candidate for indexing. Secondly, Date did not invent a method, he devised a model. There are endless ways that model can be applied, and while Date certainly wrote a seminal text on the application of his model, it is absurd to conflate the model with possible ways to apply it, not to mention irrelevant to the meaning of cardinality in datamodelling. Thirdly, normalisation serves to prevent update anomalies and eliminate redundant storage. It does not improve performance in and of itself, although it will often afford opportunities for better indexing. — Preceding unsigned comment added by PeterWone (talkcontribs) 05:59, 21 December 2011 (UTC)[reply]

I fully agree with the previous three commentators. Not only is the article utter crap but it's very badly written too: just look at the second sentence! The first commentator suspects a confusion with E-R modelling. That may be the case but on the university courses I was involved with in the UK over many years (namely, those offered by The Open University), the property in question, of a relationship between two entity types, was called the degree, not the cardinality. I strongly recommend this article for summary deletion.

AndrewWarden (talk) 15:32, 21 July 2015 (UTC)[reply]

This article is very very low in wiki-links and "See also" links!

Please help upgrading its connectivity. 93.172.178.33 (talk) 12:24, 17 November 2014 (UTC)[reply]

This article is also low on examples

The german version is much better. https://de.wikipedia.org/wiki/Kardinalit%C3%A4t_(Datenbankmodellierung)

If there is no other related article I'd like to enhance it with translations from the german version Dirk Hoeschen (talk) 10:22, 3 December 2015 (UTC)[reply]