mirror of https://github.com/apache/cassandra
Fix paths to images
Signed-off-by: Nikita Eshkeev <kastolom@gmail.com>
This commit is contained in:
parent
7e74f4bdb8
commit
515cb0e1c2
|
|
@ -30,7 +30,7 @@ underlined. Relationships between entities are represented as diamonds,
|
|||
and the connectors between the relationship and each entity show the
|
||||
multiplicity of the connection.
|
||||
|
||||
image::data_modeling_hotel_erd.png[image]
|
||||
image::images/data_modeling_hotel_erd.png[image]
|
||||
|
||||
Obviously, in the real world, there would be many more considerations
|
||||
and much more complexity. For example, hotel rates are notoriously
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ informative way to visualize the relationships between queries and
|
|||
tables in your designs. This figure shows the Chebotko notation for a
|
||||
logical data model.
|
||||
|
||||
image::cassandra:developing/data-modeling/data_modeling_chebotko_logical.png[image]
|
||||
image::images/data_modeling_chebotko_logical.png[image]
|
||||
|
||||
Each table is shown with its title and a list of columns. Primary key
|
||||
columns are identified via symbols such as *K* for partition key columns
|
||||
|
|
@ -51,7 +51,7 @@ dedicated tables for rooms or amenities, as you had in the relational
|
|||
design. This is because the workflow didn't identify any queries
|
||||
requiring this direct access.
|
||||
|
||||
image::cassandra:developing/data-modeling/data_modeling_hotel_logical.png[image]
|
||||
image::images/data_modeling_hotel_logical.png[image]
|
||||
|
||||
Let's explore the details of each of these tables.
|
||||
|
||||
|
|
@ -127,7 +127,7 @@ shows a logical data model for reservations. You'll notice that these
|
|||
tables represent a denormalized design; the same data appears in
|
||||
multiple tables, with differing keys.
|
||||
|
||||
image::cassandra:developing/data-modeling/data_modeling_reservation_logical.png[image]
|
||||
image::images/data_modeling_reservation_logical.png[image]
|
||||
|
||||
In order to satisfy Q6, the `reservations_by_guest` table can be used to
|
||||
look up the reservation by guest name. You could envision query Q7 being
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ notation for physical data models. To draw physical models, you need to
|
|||
be able to add the typing information for each column. This figure shows
|
||||
the addition of a type for each column in a sample table.
|
||||
|
||||
image::cassandra:developing/data-modeling/data_modeling_chebotko_physical.png[image]
|
||||
image::images/data_modeling_chebotko_physical.png[image]
|
||||
|
||||
The figure includes a designation of the keyspace containing each table
|
||||
and visual cues for columns represented using collections and
|
||||
|
|
@ -61,7 +61,7 @@ As you work to create physical representations of various tables in the
|
|||
logical hotel data model, you use the same approach. The resulting
|
||||
design is shown in this figure:
|
||||
|
||||
image::cassandra:developing/data-modeling/data_modeling_hotel_physical.png[image]
|
||||
image::images/data_modeling_hotel_physical.png[image]
|
||||
|
||||
Note that the `address` type is also included in the design. It is
|
||||
designated with an asterisk to denote that it is a user-defined type,
|
||||
|
|
@ -86,7 +86,7 @@ first iteration of your physical data model design, assume you're going
|
|||
to manage this denormalization manually. Note that this design could be
|
||||
revised to use Cassandra's (experimental) materialized view feature.
|
||||
|
||||
image::cassandra:developing/data-modeling/data_modeling_reservation_physical.png[image]
|
||||
image::images/data_modeling_reservation_physical.png[image]
|
||||
|
||||
Note that the `address` type is reproduced in this keyspace and
|
||||
`guest_id` is modeled as a `uuid` type in all of the tables.
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ to obtain detailed description of the hotel. The act of booking a room
|
|||
creates a reservation record that may be accessed by the guest and hotel
|
||||
staff at a later time through various additional queries.
|
||||
|
||||
image::cassandra:developing/data-modeling/data_modeling_hotel_queries.png[image]
|
||||
image::images/data_modeling_hotel_queries.png[image]
|
||||
|
||||
_Material adapted from Cassandra, The Definitive Guide. Published by
|
||||
O'Reilly Media, Inc. Copyright © 2020 Jeff Carpenter, Eben Hewitt. All
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ relationships from the conceptual model of hotels-to-points of interest,
|
|||
rooms-to-amenities, rooms-to-availability, and guests-to-rooms (via a
|
||||
reservation).
|
||||
|
||||
image::data_modeling_hotel_relational.png[image]
|
||||
image::images/data_modeling_hotel_relational.png[image]
|
||||
|
||||
== Design Differences Between RDBMS and Cassandra
|
||||
|
||||
|
|
|
|||
|
|
@ -188,7 +188,7 @@ the original design is shown in the figure below. While the `month`
|
|||
column is partially duplicative of the `date`, it provides a nice way of
|
||||
grouping related data in a partition that will not get too large.
|
||||
|
||||
image::data_modeling_hotel_bucketing.png[image]
|
||||
image::images/data_modeling_hotel_bucketing.png[image]
|
||||
|
||||
If you really felt strongly about preserving a wide partition design,
|
||||
you could instead add the `room_id` to the partition key, so that each
|
||||
|
|
|
|||
|
|
@ -150,7 +150,7 @@ consist of `id` ( for partition key), magazine name and publication
|
|||
frequency as shown in Figure 1.
|
||||
|
||||
.Data Model for Q1
|
||||
image::Figure_1_data_model.jpg[image]
|
||||
image::images/Figure_1_data_model.jpg[image]
|
||||
|
||||
Another query (Q2) is to list all the magazine names by publisher. For
|
||||
Q2 the data model would consist of an additional attribute `publisher`
|
||||
|
|
@ -159,7 +159,7 @@ sorting within a partition. Data model for Q2 is illustrated in Figure
|
|||
2.
|
||||
|
||||
.Data Model for Q2
|
||||
image::Figure_2_data_model.jpg[image]
|
||||
image::images/Figure_2_data_model.jpg[image]
|
||||
|
||||
== Designing Schema
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue