I'm kicking around a small database project (sqlite or mysql) for learning purposes... figured I'd work on cataloging some of my many books ;)
Thought I had most of the tables and relationships worked out, until I started going thru and populating with some sample data from a particular book series. One of the authors writes under a pen name in this series/genre, but under a completely different name for another genre, and his 'actual' name is something else entirely. Add to the fun that sometimes the reader (me) may not be aware that the authors name on the cover is a pen name or not.
Any ideas or suggestions for how to deal with this sort of thing in practice?
TIA,
Monte
The answers from #Adam and #mellamokb do not take account of some other complications:
Pen names can be used by authors
An author may have zero-many pen names
A pen name can belong to an author
A pen name can be a house (publisher) pen name, used by zero-many authors
A pen name is often adopted, when an author starts collaborating with one or more other authors, for the collaboration.
As you say, it is not always obvious that a name is a pen name, so you have to make the assumption that a name is real unless you know otherwise.
Obviously, dealing with all these cases is only worth while if the number of books is large - before I disposed of my book collection (approx 15,000) I was contemplating making a shift to this sort of solution, because of pen names, and because of edited anthologies and article series.
If you wish to go down this route, a good place to start is Martin Fowler's Analysis Patterns or the IEEE standards for author descriptions for its own publications.
One of many possible solutions:
tblAuthors contains authors (only real names).
tblPenNames contains pen names and relates to tblAuthors.
tblBooks has an AuthorID linking to tblAuthors and an optional PenNameID linking to tblPenNames.
Another solution
tblAuthors contains authors or pen names.
tblAuthors has an optional PenNameForAuthorID linking to another author.
tblBooks has an AuthorID linking to tblAuthors.
I would create three name-related columns in the authors table, e.g.:
authors
-------
author_id
author_name
author_alt_name
author_pseudonym
and presuming the books table has a foreign key to authors, e.g.:
books
-----
book_id
book_title
...
author_id
...then you could query for books by that author using author_id and thus independent of the various names s/he uses.
Related
While trying to move table fields that are to be translated into several languages into *_i18n tables I came to situation when my tables(author, abstract_book, publisher) were left with only 1 field. My teacher says that it is a bad practice to have tables that do not have any fields but id. Is there any better way to do this?
I was about to say an author's name (or a person's name at that) is always the same, but then I remembered that Jules Verne is really called Julio Verne in some Spanish speaking countries and we call Mr. Фёдор Михайлович Достоевский Dostojewski in German and Dostoevsky in English.
While ID-only tables look a bit strange, they can still serve for referential integrity. You cannot have a book with an author ID that doesn't exist for instance. But you could still have instances without any language entry. E.g. Book 1 was written by authors 2 and 3, but we don't know the book's title or the authors' names. That's the big drawback of this design.
For this reason I'd add columns to the tables for identification. There are three approaches to this:
Add the real name (author's name, book's title, publisher's name) to the table. That would be the author 'Достоевский' for instance.
Add the name in a default language (e.g. English) to the table. That would be the author 'Dostoevsky' for instance. With this approach you would ensure that data for the default language would be complete. (While data in other languages may have gaps.)
Add a reference to the i18n table's row (again original language or default language) to the table. This, however, has the problem that you want to have the reference not nullable, so the tables would be cross referenced. This calls for deferrable constraints and these are not available in MySQL.
Whichever of these three approaches you prefer, they all do the same: The table has an ID and a name/title. Thus you have a default, when an I18N entry is missing. And you can detect errors. If author 1 is called 'Jules Verne' in the author table and his French name is 'Jules Verne' and his English name is 'Mary Shelley', then you know which entry is incorrect :-)
I have two sets of data that are near identical, one set for books, the other for movies.
So we have things such as:
Title
Price
Image
Release Date
Published
etc.
The only difference between the two sets of data is that Books have an ISBN field and Movies has a Budget field.
My question is, even though the data is similar should both be combined into one table or should they be two separate tables?
I've looked on SO at similar questions but am asking because most of the time my application will need to get a single list of both books and movies. It would be rare to get either books or movies. So I would need to lookup two tables for most queries if the data is split into two tables.
Doing this -- cataloging books and movies -- perfectly is the work of several lifetimes. Don't strive for perfection, because you'll likely never get there. Take a look at Worldcat.org for excellent cataloging examples. Just two:
https://www.worldcat.org/title/coco/oclc/1149151811
https://www.worldcat.org/title/designing-data-intensive-applications-the-big-ideas-behind-reliable-scalable-and-maintainable-systems/oclc/1042165662
My suggestion: Add a table called metadata. your titles table should have a one-to-many relationship with your metadata table.
Then, for example, titles might contain
title_id title price release
103 Designing Data-Intensive Applications 34.96 2017
104 Coco 34.12 2107
Then metadata might contain
metadata_id title_id key value
1 103 ISBN-13 978-1449373320
2 103 ISBN-10 1449373320
3 104 budget USD175000000
4 104 EIDR 10.5240/EB14-C407-C74B-C870-B5B6-C
5 104 Sound Designer Barney Jones
Then, if you want to get items with their ISBN-13 values (I'm not familiar with IBAN, but I guess that's the same sort of thing) you do this
SELECT titles.*, isbn13.value isbn13
FROM titles
LEFT JOIN metadata isbn13 ON titles.title_id = metadata.title_id
AND metadata.key='ISBN-13'
This is a good way to go because it's future-proof. If somebody turns up tomorrow and wants, let's say, the name of the most important character in the book or movie, you can add it easily.
The only difference between the two sets of data is that Books have an
IBAN field and Movies has a Budget field.
Are you sure that this difference that you have now will not be
extended to other differences that you may have to take into account
in the future?
Are you sure that you will not have to deal with any other type of
entities (other than books and movies) in the future which will
complicate things?
If the answer in both questions is "Yes" then you could use 1 table.
But if I had to design this, I would keep a separate table for each entity.
If needed, it's easy to combine their data in a View.
What is not easy, is to add or modify columns in a table, even naming them, just to match requirements of 2 or more entities.
You must be very sure about future requests/features for your application.
I can't image what type of books linked with movies you store thus a lot of movies have different titles than books which are based on. Example: 25 films that changed the name.
If you are sure that your data will be persistent and always the same for books and movies then you can create new table for example Productions and there store attributes Title, Price, Image, Release Date, Published. Then you can store foreign keys of Production entity in your tables Books and Movies.
But if any accident happen in the future you will need to rebuild structure or change your assumptions. But anyway it will be easier with entity Production. Then you just create new row with modified values and assign to selected Book or Movie.
Solution with one table for both books and movies is the worst, because if one of the parameters drive away you will add new row and you will have data for first set (real book and non-existing movie) and second set (non-existing book and real movie).
Of course everything is under condition they may be changes in the future. If you are 100% sure, then 1 table is enough solution, but not correct from the database normalization perspective.
I would personally create separate tables for books and movies.
You set up a database company, ArtBase, that builds a product for art galleries. The core of this product is a database with a schema
that captures all the information that galleries need to maintain.
Galleries keep information about artists, their names (which are
unique), birthplaces, age, and style of art.
For each piece of artwork, the artist, the year it was made, its
unique title, its type of art (e.g., painting, lithograph, sculpture,
photograph), and its price must be stored.
Pieces of artwork are also classified into groups of various kinds,
for example, portraits, still lifes, works by Picasso, or works of the
19th century; a given piece may belong to more than one group. Each
group is identified by a name (like those just given) that describes
the group.
Finally, galleries keep information about customers. For each
customer, galleries keep that person’s unique name, address, total
amount of dollars spent in the gallery (very important!), and the
artists and groups of art that the customer tends to like.
Draw the ER diagram for the database.
Is the following ERD correct?
Is it possible that a group has zero Artworks?
Is it possible that the Artist didn't produce any artwork but still sits in the database?
1) You used ID as a PK in Artist and Artwork. This is a good thing as the use of an unique name (as requested in the business model) is wrong: after all, two pieces of art or two artists may bear the same name. However, you did respect the business model for the Customer entity whose PK is Name.
You can choose to make a good ERD and use ID as a surrogate PK for Artwork, Artist, and Customer; or respect the business model you were given and use Name as a PK for these three entities. Personally, I'd go with the former.
The following two questions can't be answered given the business model only; the answers below reflect the cardinality in the specific ERD you designed.
2) Yes, because according to the ERD a Group includes from 0 to N Artworks;
3) Yes, because according to the ERD although an Artist makes from 1 to N Artworks (and therefore there wouldn't be the need to insert an Artist in the database if he didn't do any Artwork) there is still a relationship between Customer and Artist in the sense that a Customer likes from 1 to N Artists.
Therefore an Artist can be in the database even if he didn't produce any Artwork (yet), provided that he is liked by at least one Customer. If an Artist didn't do any Artwork and is not liked by any Customer, he won't be in the database.
Missing some context information here, especialy some cadinality information. Pay attention to yourself asking questions about the context:
Is it possible that a group has zero Artworks?
Is it possible that the Artist didn't produce any artwork but still
sits in the database?
This information should be given by you (or by the presenting problem). If this is a work of your course or your college, your instructor needs to better explain the present context. If you are already working as a DBA or data modeler, please look for more information about this problem. It's almost indescribable the importance of a context in the development of an ER-Diagram. Keep this in mind: Without a well-defined context, the problem (the situation) is uncertain, and so is missing information to complete the reflection of a real-world situation. In short:
No complete context, no diagram (without a diagram, there is no system!).
I will make this diagram with you step-by-step, but I'll take some assumptions due to lack of information (context) here. I will give my opinion on certain resources used in ER-Diagram, but that does not mean that I'm saying you're layman. I am just showing my thought, which shows how I learned that here in my country. I believe that you are as capable as I am, ok? Well, let's begin...
Entities in ER-Diagram are defined when we have attributes / properties. According to your description, we can see immediately 3 entities here:
Customers
Artists
Artworks
Relationships exists to express links between entities. The most obvious relationship here is between Artists and Artworks, Don't you agree?
For each piece of artwork, the artist...
In accordance with the context revealed, all artwork has a unique artist (always), but it is uncertain if an artist always has one, multiple, or zero artworks. I SUPPOSE that an artist can have many or no artwork. That being said, we see that artists to artworks have a cardinality 0 to N, because, again, an artist may have made several or no artwork at all.
So far we have defined three entities, and linked two of them. Let's continue...
...its type of art (e.g., painting, lithograph, sculpture, photograph)...
If an artwork has only a single type of art, and an art type is defined only by its name, then we have here what is called a Functional Redundancy (translated from the Portuguese term "Redundância Funcional"). In spit summary, Functional Redundancies are like relationships between two entities, and serve to save you the trouble of repeating the same field in multiple columns in a table (which would be susceptible to errors). In a Conceptual Model, they are represented as a field in an entity with the suffix "(R)" (without the double-quotes).
If an entity has a field (column) like a Functional Redundancy, but with different values (multiple), then we have what is called Multivalued Field (also translated from the Portuguese term "Campo Multivalorado"). These are fields in entities that have the suffix "*" (also without the double-quotes).
This is not the case of the type of artwork, but it would until now for the groups of each artwork:
Pieces of artwork are also classified into groups of various kinds,
for example, portraits, still lifes, works by Picasso, or works of the
19th century; a given piece may belong to more than one group.
This would be true if groups only possess names, and no other entity relate to them. But then you said:
and groups of art that the customer tends to like.
This has changed things a bit. Groups no longer is a Multivalued Field in Artworks entity and becomes an entity with two relationships, one for Customers and one for Artworks. The relationship between Groups and Customers reveals the preferred art groups by customers. The relationship between groups and artworks shows which art groups a artwork is related. Now let's talk about the cardinalities of these relationships.
...a given piece may belong to more than one group. [...]
...and groups of art that the customer tends to like. [...]
Concerning Groups and Artworks, the word "may" says a lot to me. It says that something may or may not be effective. Still, it is uncertain whether an artwork can exist without at least one related group. Because of this, I see a 1 to N relationship from Artworks to Groups.
Conversely, the opposite process is not clear. I believe that there may be groups unrelated to artworks, perhaps because they are new groups created in a given time. So I see a relationship of 0 to N from Groups to Artworks.
Let's talk about Groups and Customers. It seems to me that a customer like at least one group of art. So I see a 1 to N relationship from Customers to Groups.On the opposite side, as already said, it would be possible to add new groups without automatically tying at least one customer to it. I think there may be new groups unrelated to customers. So guess what? We have a relationship of 0 to N from Customers to Groups.
So far we have identified another entity, a Functional Redundancy,
and two relationships with their respective cardinalities. Let's keep going...
and the artists ... that the customer tends to like.
There is a close connection here between two entities, Customers, and Artists. This relationship tells us what artists the customers like. If a customer must like at least one artist, then we have a 1 to N relationship from Customers to Artists. If a customer may or may not like an artist, then we have a relationship 0 to N.
If an artist has zero or more customers who appreciate it, then we have a relationship 0 to N from Artists to Customers. If an artist has at least one client who appreciates it's work, then we have a 1 to N relationship from Artists to Customers.
Lastly...
Galleries keep information about artists, [...] and style of art.
If multiple artists can share a single same art style, then we have a Functional Redundancy here. If several artists have various art styles, then we have a Multivalued Field.
After much talk, I came up with an ER-Diagram presented by your context and assumptions made by me:
NOTE: The green points highlights major assumptions.
Is this right? Is this the correct diagram? The correct answer would be (from me to you):
I do not know...
Without a concrete context, we can not finalize a diagram correctly. My tip is that you finish your context. Only then you will have a correct diagram.
Oh, one more thing. What would be this "money spent" attribute? If customers can buy artworks, it would represent a new relationship between Artworks and Customers. This relationship would represent the purchase of artworks from customers (called "ORDERS", for instance). If not so, skip this paragraph.
If I have forgotten something, please say so. If you have questions feel free to ask, I'm here to help you.
i have to translate a DB into a DM, but i have some doubt about, this is the DB schema:
http://i.stack.imgur.com/PHha1.png
This is a simple DB to store authors, books and various othe things (foreign keys of author table are wrongs and the table "book" as another field called year). I should built a DM to analyse how authors works trought years (coauthors and books). I would like to add even a way to see citations of an author... The DM i'm building is something like this:
http://i.stack.imgur.com/MPCTL.png
Now my doubt is: how could i add citations in this datamart?
PS for citation i mean a book that cites an author and i'm working with kettle and penthao
Citations and book authorship have different granularities. As such, they should be in different fact tables.
How I would do it:
Citations fact table: grain is 1 citation of 1 person in 1 book. external keys are for the time dimension, cited author dimension, author dimension, book dimension and whatever else you may need. This data mart gives you directly counts of citations of person X, broken down by time, book author, etc.
Authorship fact table: one may think that the grain is 1 book, but in fact it's not. The grain is 1 author of 1 book. That's the most atomic level of data. To get a book count you can either define that 1 book co-authored by 1 person counts as 1 book, counts as 0.5, as 1/Number of co-authors or any other useful metric. If you also want to count books, you should use the 1/N metric, together with any other you find useful.
Co-authorship relationships: trying to determine the authors that publish the most together: this is trickier. Here the fact granularity is also authorship, but with 1 entry for each pair of co-authors available. So, if a book is written by Albert, Bill and Charles, you'd get 1 entry with author Albert and co-author Bill, one for Albert as author and Charles as co-author, etc (all 6 combinations). This allows you to get a full list of authors and their co-authors and count how many times they appear combine, but everything will show up as double counted: Albert+Bill and Bill+Albert shows up twice. The best way to filter out the duplicates would be to either define "authors in alphabetical order, where Albert+Bill, Albert+Charles and Bill+Charles are stored but not the others, or on the client side, removing duplicates as a query post-processing.
To combine multiple metrics arriving from multiple data marts, you should add a post-processing layer to your visualisation tool, to cross reference all these results.
Finally, one comment: this problem doesn't seem to be best treated with a data mart. Book metadata doesn't have a fixed data schema and a schemaless structure may be best to do all those searchs (look into Elastic Search and Mongo DB, they are perhaps better suited for this specific problem.
My Set-up: I have two tables: tblAuthors and tblBooks. tblAuthors includes a list authors: Kurt Vonnegut, Frank Herbert, J. K. Rowling, John Nichols, etc.. tblBooks includes a list of books: Slaughter House Five, Cat's Craddle, Monkey House, Dune, Harry Potter, Milagro Beanfield War, etc..
There is a one-to-many relationship between tblBooks and tblAuthors; Authors in tblAuthors is used as the primary key for this relationship. tblAuthors has a Number of Books coloumn which tells the user of the table how many books each author has written that is included in the table. Currently the user (sadly me) must input this information by hand, updating it after every book is entered and given an author. Although this is not particularly difficult because I can simply see how many books are related to the author in tblAuthors because of the relationship, it is sometimes difficult to remember to update it (not to mention a colossal pain in the butt).
I want Number of Books to update automatically as I add more books. If there is a code out there please let me know!!
I am not really familiar with VBA and could use an explanation that is geared towards someone who may not understand all of the facets of the code.
Thank you in advance for any help that you give me!
You might like to read about relational database design It is not usual to store calculated fields because the information can easily be obtained from a query.
SELECT AuthorID,
Count(BookID)
FROM Books
GROUP BY AuthorID