Theoretical definition for the number of unique values? - MySQL

[sqlservernewbie@yahoo.com]

Hi Everyone,


Here is a theoretical, and definition question for you.


In databases, we have:


Relation
a table with columns and rows


Attribute
a named column/field of a relation


Domain
a set of allowable values for one or more attributes

Tuple
a row of a relation


Degree
the number of attributes a relation contains
Number of fields in a table


Cardinality
the number of tuples/rows a relation contains




But!

What is the definition for the number of unique values in a field?

So, if you have 100 rows in a table, and the field is
the gender field, with only values of: M, F.
The result is 2 unique values.


What do we call this concept?
"the number of unique values in a column?"

Is there one?


Thanks a lot!

[Larry]

com wrote:
 

Using your definitions, it'd probably be "the cardinality of the
domain."


Larry Coon
University of California

[hpuxrac]

On Apr 12, 11:47 am, com wrote: 

distinct values

For a column or set of columns which together an index is created from
you can think of it as distinct keys

[The]

com wrote: 

(Column) Cardinality = number of distinct column/attribute values.
Table Cardinality = number of rows in a table.

--
Jeroen

[David]

In article <461e877b$0$328$xs4all.nl>,
Spam.Please.invalid says... 
>
> (Column) Cardinality = number of distinct column/attribute values.
> Table Cardinality = number of rows in a table.[/ref]

Shouldn't that be *distinct* (non-duplicate) rows in the table?


--
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).

[Gord]

On Apr 12, 4:14 pm, David Kerber
<com> wrote: [/ref]
> [/ref]
> [/ref]
> [/ref]
> [/ref]
> [/ref]
> [/ref]
> [/ref]
> [/ref]
> [/ref]
> [/ref]
> [/ref]
> [/ref]
> [/ref]
> [/ref]
> 
>
> Shouldn't that be *distinct* (non-duplicate) rows in the table?[/ref]

I believe that one of the cardinal rules (pun intended) of RDBMS
theory is that a table can never have duplicate rows.
 

[Martijn]

 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > Shouldn't that be *distinct* (non-duplicate) rows in the table?[/ref]
>
> I believe that one of the cardinal rules (pun intended) of RDBMS
> theory is that a table can never have duplicate rows.[/ref]

True. There's no point in having duplicate rows, cause you can't tell
which one you're handling :-)



--
Martijn Tonies
Database Workbench - development tool for MySQL, and more!
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com

[David]

In article <461f2fcd$0$11982$news.xs4all.nl>,
removethis.com says... 
> >
> > I believe that one of the cardinal rules (pun intended) of RDBMS
> > theory is that a table can never have duplicate rows.[/ref]
>
> True. There's no point in having duplicate rows, cause you can't tell
> which one you're handling :-)[/ref]

True, but are you telling me you've never had it happen accidentally??


--
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).

[DA]

David Kerber wrote:
 
>
> True, but are you telling me you've never had it happen accidentally??[/ref]

Assuming the database is being used as more than an electronic form
of Excel or 3x5 cards ... no. Primary key constraints were invented
for a reason. Like seat belts they are most useful when used.
--
Daniel A. Morgan
University of Washington
damorganx.washington.edu
(replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org